當面對數億、數十億筆資料時，若每次查詢都必須掃描全表，效能勢必崩潰。ClickHouse 提供了靈活的 分區 (Partitioning) 與 Partition Pruning (分區裁剪) 技術，讓你在查詢時僅需掃描「真正相關的資料區塊」，大幅減少 I/O 與查詢延遲。

什麼是 Partition（分區）？

在 ClickHouse 中，Partition 是一種邏輯資料切分單位，資料會根據指定的 Partition Key (表達式) 被切分成獨立的資料區塊（目錄），這些區塊在查詢時可以根據條件篩選，避免全表掃描。

重要特性：

• Partition 是 MergeTree 引擎的核心結構之一。
• Partition Key 可以是任意表達式（如 toYYYYMM(date)、device_id、region_id）。
• Partition 是「物理檔案目錄」級別的切分，對查詢優化效果非常明顯。
• Partition 切分範圍越小，查詢時能跳過的資料越多，但會增加小檔案數量與合併負擔。

Partition 與 Primary Key 的差異

兩者是互補關係，Partition 用於粗略範圍裁剪、Primary Key 用於精細定位。

Partition Pruning（分區裁剪）原理

Partition Pruning 是 ClickHouse 在查詢時根據 WHERE 條件，自動判斷哪些 Partition 是不可能有資料的，並直接跳過讀取這些資料區塊。

範例：

CREATE TABLE page_views
(
    event_date Date,
    user_id UInt64,
    page String
) ENGINE = MergeTree
PARTITION BY toYYYYMM(event_date)
ORDER BY (event_date, user_id);

查詢：

SELECT count() FROM page_views
WHERE event_date >= '2025-08-01' AND event_date < '2025-08-02';

• ClickHouse 會根據 toYYYYMM(event_date) 的 Partition Key 判斷，只有 202508 分區有可能符合條件，其他分區會被直接跳過，不會進行掃描。

Partition Key 設計策略

Partition 粒度與效率平衡

查詢如何確認 Partition Pruning 是否生效？

1. 使用 EXPLAIN：

EXPLAIN PLAN SELECT * FROM page_views WHERE event_date = '2025-08-01';

2. 查詢分區讀取統計 (system.parts)：

SELECT
    partition,
    active,
    rows,
    bytes_on_disk
FROM system.parts
WHERE table = 'page_views' AND active;

3. 觀察查詢 profile events：

SET send_logs_level = 'trace';
SELECT count() FROM page_views WHERE event_date = '2025-08-01';

在查詢 Profile Events 中可以看到 read_rows 與 read_bytes 是否明顯降低。

實際案例

假設一個月 30 億筆網站點擊資料，未使用分區時查詢單日流量需掃描全表，I/O 延遲數十秒。若將 Partition Key 設為 toYYYYMMDD (event_date)：

• 單日查詢只需掃描 1/30 的資料量。
• 查詢延遲可從 30 秒降至 1 秒以內。
• 結合 Primary Key (如 page, user_id) 可進一步精確篩選。

Partition 與分片 (Sharding) 的關係

兩者可結合設計，例如：

• 分片鍵 = user_id（負載均衡分散寫入）
• 分區鍵 = toYYYYMM(date)（加速範圍查詢）

Best Practice

結語

Partition Pruning 是 ClickHouse 面對大量資料時的查詢加速神器。透過合理設計分區策略，不僅能減少 I/O 負擔，更能讓你的 OLAP 報表與即時查詢在 TB 級資料量下依然保持 ms 級回應。